AWS再入門ブログリレー2022 AWS Elastic Beanstalk編

AWS再入門2022

#AWS Elastic Beanstalk

#AWS

杉金晋

2022.03.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさんこんにちは、杉金です。当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の 21日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2022年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。1つでも知らない機能があり、学びにつながれば幸いです。

では、さっそくいってみましょう。21日目のテーマは『AWS Elastic Beanstalk』です。

AWS Elastic Beanstalkとは

概要

AWS Elastic Beanstalk は、Java、.NET、PHP、Node.js、Python、Ruby、Go および Docker を使用して開発されたウェブアプリケーションやサービスを、Apache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするためのサービスです。作成可能な環境として、ウェブサーバ環境とワーカー環境の2種類があります。

ウェブサーバー環境
→ウェブサイト、ウェブアプリケーション、または HTTP リクエストを処理するウェブ API を実行する環境
ワーカー環境
→長時間実行するワークロードを処理するワーカーアプリケーションをオンデマンドで実行するか、スケジュールに従ってタスクを実行する環境

サービス名の読み方

Beanstalkの読み方は、ビーンストークもしくはビーンスタークです。JavaBeansと混同して私は「ビーンズトーク」とたまに呼んでしまうのですが「ス」は濁らないです。Beans+talkではなく、Bean+stalk（豆の茎）なのです。なぜ豆の茎なのか、これは私の推測ですが童話のジャックと豆の木に由来していると思われます。豆（アプリケーション）を蒔いたら大きく成長して雲（クラウド）まで伸びる、アプリケーションとクラウドの橋渡し的なサービスであることを表しているように見受けられます。

特徴

サービスの特徴としては次のものが挙げられます。

アプリケーションデプロイの多様な選択肢
アプリケーションの状態モニタリングと管理のための統一されたユーザーインターフェイス
管理された更新を使用して、最新のプラットフォームバージョンや新しいパッチを自動的に取得できる
ELBとAuto Scalingを使用して、拡張/縮小ニーズに基づいてアプリケーションを自動的にスケール
スポットインスタンスやEC2インスタンスタイプなど、アプリケーションにとって最適なAWSリソース選択できる
多彩なアプリケーションプラットフォーム

対応しているプラットフォーム

Elastic Beanstalkは、以下のプラットフォームに対応しています。

.NET Core on Linux
.NET on Windows Server
Go
Java
Node.js
PHP
Python
Ruby
Tomcat

Elastic Beanstalkで環境を作成する際に、どのプラットフォームを使用するかを選択します。

カスタムプラットフォーム

上記画像でグレーアウトされていますが、カスタムプラットフォームという選択肢もあります。自身でプラットフォームを作成することで、対応していない言語やその他のインフラストラクチャソフトウェアを使用するアプリケーション用のプラットフォームを構築できます。カスタムプラットフォームを作成するには、対応するOSであるUbuntu、RHEL、Amazon LinuxのいずれかからAMIを作成してカスタマイズを行い、Packerを使用して独自の Elastic Beanstalk プラットフォームを作成します。

主な構成要素

Elastic Beanstalkを構成する要素として主に「環境」と「アプリケーション」の2つがあります。関係性は下図のように親が「アプリケーション」で、子が「環境」になります。

それぞれの役割は、作成したアプリケーションをアップロード、管理するところが「アプリケーション」で、「環境」でアプリケーションを実際に稼働させる環境を定義します。

より具体的なイメージを掴むためにコンソール画面を紹介しますと、アプリケーションの画面は次のものです。今回はサンプルとして「test-app」というアプリケーションを作り、その配下に「test-app-dev-1」「test-app-dev-2」という2つの環境を作成しました。

続いて環境の画面です。

注意点として、アプリケーション名や環境名は一意である必要があります。異なるアプリケーションであっても同一の環境名は作成できません。

アプリケーションのアップロードと環境へのデプロイ方法

対象アプリケーションの「アプリケーションバージョン」を選択すると、アップロードしたアプリケーションとデプロイ先（環境）の一覧が表示されます。ここからアプリケーションのアップロードとデプロイを行います。

アプリケーションのアップロード方法

アプリケーションのアップロード方法ですが、アプリケーションバージョン画面の右上の方にある「アップロード」というボタンを押すと次の画面が表示されます。

区別できるようなバージョンラベル名と必要であれば説明も入れて「ファイルを選択」からアップロードするアプリケーション(war/zip）を選択します。これでアップロードすると、バージョン一覧に追加されます。アプリケーションファイルの実体は自動作成されるS3バケットに保管されます。

アプリケーションのデプロイ方法

アップロードしただけでは環境にはデプロイされません。アプリケーションをデプロイするにはバージョンラベルを選択して、アクションから「デプロイ」を選択します。

試しに「test-app_v0.2.0」を「test-app-dev-1」環境にデプロイしてみます。

対象の環境にアクセスするとデプロイ状況が確認できます。

赤枠内のヘルスマークが回転して、デプロイ処理中であることを表します。デプロイが完了するとヘルスが緑色に変わります。赤色になる場合は何かしらの問題が発生していますので、「原因」ボタンを見たり、イベントメッセージから問題を特定します。デプロイが完了するとアプリケーションバージョン一覧にも反映されます。

以上がアプリケーションのアップロードと環境へのデプロイ方法です。単にアップロードしてデプロイ先を指定するので簡単です。続いてはアプリケーションと環境の作り方を紹介します。

アプリケーションの作成方法

アプリケーション一覧画面から「新しいアプリケーションの作成」ボタンを押します。

画像を見て分かる通りアプリケーションはほぼ入れ物ですので、アプリケーション名を決めて必要に応じて説明とタグを設定します。作成するとアプリケーションの一覧に追加されます。アプリケーションの作成はこれだけです。

環境の作成方法

対象アプリケーションの環境一覧画面から「新しい環境の作成」ボタンを押します。まず作成する環境のタイプを選びます。今回はウェブサーバー環境を使って説明していきます。

環境タイプを決めたら、続いては環境名やドメイン、説明を決めていきます。ドメインはxxxx.[リージョン名].elasticbeanstalk.comという名前で作成されます。任意の値を決めるか自動生成のランダムなものを使用します。

独自ドメインでアクセスしたい場合は、独自ドメインのDNSにCNAMEレコードで「xxxx.[リージョン名].elasticbeanstalk.com」を値に指定します。Route53で独自ドメインを管理している場合はエイリアスレコードを使用できます。Route53のCNAMEレコードとエイリアスレコードの比較は以下が参考になります。分かりやすいところですとCNAMEクエリと違ってエイリアスクエリは課金されないことです。

その次はプラットフォームとデプロイするアプリケーションを選択します。特にインフラにこだわり無ければ「環境の作成」ボタンを押します。より細かく設定するには「より多くのオプションの設定」ボタンを選択します。

「より多くのオプションの設定」ボタンを選択すると、別の画面に移動してプリセットとカテゴリ毎に細かく設定できます。

設定可能な項目

より多くのオプションの設定から、どのような設定カテゴリがあるかを表にしました。

カテゴリ	設定可能な内容（一例）
ソフトウェア	プロキシサーバの種類、AWS X-Ray、ログ出力（S3やCloudWatch Logs ）、環境プロパティ
インスタンス	ルートボリュームのタイプ、サイズ、EC2インスタンスのセキュリティグループ
容量	Auto Scaling グループ設定（フリート構成、インスタンスタイプ、AMI ID、AZ配置）、スケーリングトリガー
ロードバランサー	ロードバランサーの種類、リスナー、プロセス、ルール、ログ保存設定
ローリング更新とデプロイ	アプリケーションのデプロイメントポリシー、設定の更新方法、ヘルスチェックの要件とデプロイメントタイムアウトのカスタマイズ
セキュリティ	サービスロール、EC2のキーペアやIAMロールの設定
モニタリング	ヘルスレポートの設定、ヘルスモニタリングルールのカスタマイズ、CloudWatch Logs へのヘルスイベントのストリーミング
管理された更新	定期的にプラットフォームを自動更新するかの設定、更新レベル、メンテナンスウィンドウの時間帯
通知	環境からの重要イベントを受け取るメールアドレスを指定
ネットワーク	使用するVPC、ELBやインスタンス、データベースが使用するサブネット
データベース	RDSのデータベースを設定（DBエンジン、インスクラス、ストレージ、MultiAZ）、DB削除ポリシー
タグ	環境内のリソースにタグを付与

ローリング更新とデプロイ

上記の設定カテゴリの中でも特に押さえておきたいのがローリング更新とデプロイです。既存環境に新たなアプリケーションをデプロイしたときにどのように反映させるか、既存環境のインフラ設定を変更したときにどのように設定変更するかを定義するものです。アプリケーションと環境それぞれに定義します。

アプリケーションのデプロイメントポリシー

種類としては5つあります。

1回にすべて（All at once）
ローリング（Rolling）
追加バッチとローリング（Rolling with additional batch）
変更不可（Immutable）
トラフィックの分割（Traffic splitting ：ALBのみ使用可能、NLBやCLBでは使用不可）

それぞれの比較については以下のリンクが参考になります。

ひとつポリシーを取り上げると、Immutableは稼働環境に与える影響が少ないのですが同一環境を横に作って向き先を切り替える仕組みのためデプロイに時間がかかります。利用ユーザーに影響を与えたくない場合は影響の少なさを重視、開発環境などの影響があっても問題ない場合は速度重視のようなポリシーの選び方もできます。

環境の設定変更における更新タイプ

種類としては4つあります。

無効（Disabled）
ヘルスにもとづくローリング（Rolling Based on Health）
時間にもとづくローリング（Rolling Based on Time）
変更不可（Immutable）

それぞれの比較については以下のリンクが参考になります。

デプロイメントポリシーについては、絵で動きを見たほうが分かりやすいため以下の記事が参考になります。

Elastic Beanstalkを使用したブルーグリーンデプロイメント

上記の参考記事にも記載されていますが、デプロイポリシーとは別の機能でブルーグリーンデプロイメントを実行できます。それが「環境URLのスワップ」です。

環境作成時に割り当てた環境URLを入れ替えるもので、対象の環境を選び「環境URLのスワップ」を選択し、入れ替えたい環境を指定します。

管理しているDNSでもブルーグリーンデプロイメントは実現できますが、Elastic Beanstalkの機能だけでできるところがポイントです。注意点としてはURLは切り替わっても環境名は入れ替わらないため、上記の場合はtest-app-dev-1の環境URLがtest-app-dev-2〜になり、test-app-dev-2の環境URLがtest-app-dev-1〜になります。

EB CLI

ここまでAWSマネジメントコンソールを使用した設定方法を紹介しました。他にもAWS CLIやSDKも使えますが、EB CLIというElastic Beanstalk専用のコマンドラインツールが存在します。Elastic Beanstalkを使い倒すのであれば是非とも導入しておきたいツールです。

インストール方法（Mac、Windows）

初期設定(eb init)

EB CLIをインストールしたら、eb initコマンドを実行してリージョンの選択やプロジェクトディレクトリの設定、操作するアプリケーションの選択を行います。

環境操作

初期設定が終わったら後は実際にコマンドを使用して環境を管理/操作します。

より細かな設定をしたい場合(.ebextensions)

EC2インスタンスからメールを送信したり、S3やEFSに設定ファイルを配置しておき、それをデプロイ時にロードしたいといったカスタマイズも必要になることもあります。コンソールから設定できないものはebextensionsを利用します。具体的には.ebextensionsというディレクトリを作り、その中に設定ファイルを記述して、アップロードするアプリケーションとまとめてzip化してアップロードすることで、デプロイ時に反映してくれます。

.ebextensionsに配置するファイルの例

ファイル名：.ebextensions/network-load-balancer.config

option_settings:
  aws:elasticbeanstalk:environment:
    LoadBalancerType: network

上記は環境ロードバランサーのタイプを Network Load Balancer に設定するものです。コンソールやCLIでも設定できるため、設定方法には優先順位が存在します。

環境作成時の設定優先順位

優先度の高い順に並べると次のようになります。

環境に直接適用される設定 – 環境の作成時または環境の更新時に、Elastic Beanstalk コンソール、EB CLI、AWS CLI、SDK などのクライアントによって Elastic Beanstalk API で指定された設定です。
保存済み設定 – 指定されている場合、環境に直接適用されないオプションの設定が、保存済み設定からロードされます。
設定ファイル (.ebextensions) – 環境に直接適用されず、保存済み設定でも指定されていないオプションの設定が、アプリケーションソースバンドルのルートにある .ebextensions フォルダの設定ファイルからロードされます。

設定ファイルはアルファベット順に実行されます。たとえば、.ebextensions/01run.config は .ebextensions/02do.config の前に実行します。
デフォルト値 – 設定オプションにデフォルト値がある場合、オプションが上記のいずれのレベルにも設定されていない場合にのみ適用されます。

EC2インスタンスのOSに対するebextensions設定

以下のキーを使用することで、EC2インスタンスのOS上でカスタマイズを実行できます。

Linuxサーバーの場合

キー	できること
packages	パッケージ済みのアプリケーションとコンポーネントをダウンロードしてインストール
groups	Linux/UNIX グループを作成して、グループ ID を割り当て
users	Linux/UNIX ユーザーを EC2 インスタンス上に作成
sources	公開 URL からアーカイブファイルをダウンロードし、EC2 インスタンス上のターゲットディレクトリに解凍
files	EC2 インスタンス上にファイルを作成
commands	EC2 インスタンスでコマンドを実行
services	インスタンスが起動されるときに開始または停止する必要のあるサービスを定義
container_commands	アプリケーションのソースコードに影響するコマンドを実行。`leader_only` を使用して、1 つのインスタンスでコマンドを実行するか、テストコマンドが `test` と評価される場合のみコマンドを実行するよう `true` を設定できる [注釈]`leader_only`コマンドは、環境の作成およびデプロイ中のみ実行されます。他のコマンドやサーバーカスタマイズオペレーションは、インスタンスがプロビジョニングまたは更新されるたびに実行されます。`leader_only`コマンドは、AMI ID やインスタンスタイプの変更などの起動設定の変更によって実行されることはありません。

Windowsサーバーの場合

キー	できること
packages	パッケージ済みのアプリケーションとコンポーネントをダウンロードしてインストール
sources	公開 URL からアーカイブファイルをダウンロードし、EC2 インスタンス上のターゲットディレクトリに解凍
files	EC2 インスタンス上にファイルを作成
commands	EC2 インスタンスでコマンドを実行
services	インスタンスが起動されるときに開始または停止する必要のあるサービスを定義
container_commands	`container_commands` キーを使用して、アプリケーションのソースコードに影響するコマンドを実行。`leader_only` オプションを使用して、1 つのインスタンスでコマンドを実行するか、テストコマンドが `test` と評価される場合のみコマンドを実行するよう `true` を設定できる [注釈]`leader_only`コマンドは、環境の作成およびデプロイ中のみ実行されます。他のコマンドやサーバーカスタマイズオペレーションは、インスタンスがプロビジョニングまたは更新されるたびに実行されます。

ebextensionsは奥が深いです。いくつかサンプルが用意されていますので、記事最後の参考情報にリンクを記載します。

カスタムAmazonマシンイメージ（AMI）の使用

環境カスタマイズの異なるアプローチとして、カスタムAMIも使用できます。

モニタリング

Elastic Beanstalk環境のモニタリング方法を紹介します。

環境のモニタリング画面

コンソールの対象環境の「モニタリング」からモニタリング状況のダッシュボードが表示されます。

ヘルスレポート

環境にアクセスすると概要画面に「ヘルス」が表示されます。

状態を表す色とその説明を下表にまとめました。

色	説明
グレー	環境が更新中です
グリーン	環境が最新のヘルスチェックで合格になりました。環境内の少なくとも 1 つのインスタンスが使用可能であり、リクエストを受け取っています
イエロー	対象環境が 1 つ以上のヘルスチェックで失格になりました。環境へのいくつかのリクエストが失敗しています
レッド	対象環境が 3 つ以上のヘルスチェックで失格になったか、環境のリソースが使用不可になっています。リクエストは一貫して失敗しています